Output ES module from rollup#224
Conversation
|
Hmm. I thought the way it is currently set up was sufficient as we simply mimicked the way React itself was set up. If I recall correctly, React doesn't have an es module build does it? |
|
You are probably right about react, and it might be a good reason for it not having one yet. (We actually use preact that provides an es module build). I see now that you had multiple outputs, including an es module, thats probably why it worked in our build prior to v1.0.12. However when you removed the module and made the index.js entrypoint the only option, rollup (or their commonjs plugin) is no longer able to resolve what is exported. It might be some bad config on our end, but regardless of that I am not sure if there is a reason not to provide an es module as an alternative. UMD is not statically analyzable afaik and generally used as fallback builds(?), which makes it harder for bundlers to leverage properties like tree-shaking etc. |
|
Is there any reason to use |
|
Node went with .mjs, and mozilla Personally not important with minification and as you say it will probably be minified anyways, but would it pose any issue? Sourcemaps should be available, and it might be preferable for users loading the module from a CDN or similar. |
|
Okay. In that case, we can keep it |
|
View your CI Pipeline Execution ↗ for commit 7bcb5cc
☁️ Nx Cloud last updated this comment at |
3 participants
After v1.0.12 our rollup build broke due to namedExports no longer being available to rollup due to the
NODE_ENV+require()dev/prod logic. That forces us to explicitly alias all react-query exports in our rollup-config, however building an es module makes rollup happy.I guess the dev / prod build is not that required for es modules, and libraries like redux only provides a single minified es build.